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APOLLO EXPERIENCE REPORT 


REAL-TIME AUXILIARY COMPUTING FACILITY DEVELOPMENT 

By Charles E. Allday 
Manned Spacecraft Center 

SUMMARY 


The Apollo Real-Time Auxiliary Computing Facility, which was an expansion of 
the facility used during Project Mercury and the Gemini Program, provided support 
for all aspects of flight control. Mission support, mission-simulation support, and 
engineering evaluations also were included in the scope of the facility, and computer 
programs were developed specifically for those areas. The organization, management, 
and control of the facility were given to a special group of trajectory analysts. The 
analysts, who had experience in facility activities, had the responsibility for the devel- 
opment of the facility to provide complete mission-support capability. The existing 
computer programs were used as the basis for the software; however, strict control 
was placed on the input and output formats and on the program interfaces and 
verification. 

The real-time auxiliary computing function and facility were developed to perform 
unexpected real-time trajectory computations and evaluations of trajectory problems 
that developed during the missions. The facility also provided the capability to perform 
computations that were beyond the time -limited constraints of the real-time program 
and the capability to use programs that were too large and cumbersome to be used in 
real-time computations. Requirements that were established too late in the real -time - 
program development were accommodated by the facility. In addition, the facility pro- 
vided the flight controller the opportunity to evaluate programs and displays in a 
real-time environment before implementing them in the real-time system. By the use 
of the facility, existing available programs and personnel were used to provide an 
almost unlimited real-time capability for problem solving. 


INTRODUCTION 


The Real-Time Auxiliary Computing Facility (RTACF) evolved from the 
trajectory planning and contingency analysis in support of Project Mercury. Real-time 
support activities were the result of trajectory -related problems that developed during 
the Mercury mission simulations. The RTACF was expanded during the Gemini Pro- 
gram to include engineering evaluation support for all areas of flight control. Computer 
programs were developed specifically for mission and mission- simulation support. 



The scope of the function was expanded further for the Apollo Program to include prime 
mission-support functions in addition to the engineering evaluations; thus, the RTACF 
became a mandatory mission -support function. 

In planning for the Apollo Program, a special group was formed to organize, 
manage, and control the RTACF. This group was staffed with trajectory analysts who 
had participated previously in the RTACF activities. One of the prime responsibilities 
was to expand the RTACF computer system to provide a total mission -support capabil- 
ity. The responsibility for providing the mission -critical computations created the 
demand for the implementation of configuration control over the offline computing soft- 
ware. This goal was accomplished primarily by means of specific offline software 
verification and a common data base that could be used by all offline programs. The 
RTACF functioned as a full-scale mission-support activity until after the first manned 
lunar -landing mission. After the Apollo 11 mission, the facility gradually reverted to 
a nonmandatory, offline, on-call operation because the real -time -program flexibility 
had been increased and verified sufficiently to eliminate the need for redundant 
computations. 

The RTACF for the Apollo Program was developed because of the need to perform 
unexpected real-time trajectory computations and engineering evaluations of trajectory 
problems that developed during the mission, as well as during mission simulations. 

The RTACF was expanded to perform the following functions. 

1. Computations requiring multiple ephemerides and trajectory planning beyond 
the time -limited capability and flexibility of the real-time program 

2. Computations using large and cumbersome programs with running times too 
slow to be feasible for real-time computations 

3. Computations to satisfy requirements established too late in the real -time - 
program planning cycle to be satisfied by the real-time system (Normally, these com- 
putations were absorbed by the real-time system during later missions. ) 

4. Computations performed to provide a real-time testing ground for future 
Real-Time Computer Complex (RTCC) programs (This capability provided a means of 
evaluating a computer program in a real-time environment before the program was 
implemented in the real-time program. ) 

5. Computations to provide unlimited real-time flexibility as to the type of prob- 
lem that could be resolved by the use of the engineering analysis programs by the per- 
sonnel who were involved in all phases of the mission planning 

To accomplish these functions during Project Mercury and the Gemini Program, 
each engineer coordinated his own computing requirements, maintained his own pro- 
grams, and established his own procedures. Because of the relative simplicity of the 
RTACF function for Project Mercury and the close relationship of the people involved, 
this..pro.cedure was acceptable. The procedure extended into the Gemini Program and 
workedsEEiLfor the early missions. However, as the program matured and became 
more-cumptexiiand as the mission -control operations were transferred from the NASA 
John Ff^TfPTmTTd3r S pace Center (KSC) to the NASA Manned Spacecraft Center (MSC) 
Mission LContEntaEenter (MCC), this procedure became unworkable. Many conflicts 
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arose in the use of available equipment, in addition to the always present problem 
caused by the use of incompatible or wrong inputs, and resulted in confusion and the 
use of incorrect data for mission -control decisions. Also, much redundant programing 
occurred as the requirements increased for the later Gemini and early Apollo missions. 
To resolve these problems and to avoid future problems, the following actions were 
necessary. 

1. Creation of an organizational group responsible solely for the RTACF function 
(This function included assessing requirements, controlling hardware and software, 
establishir^ operating procedures, and acting as the point of contact with outside 
organizations. ) 

2. Development of the necessary computer facility to include communications 
with the MCC 

3. Assembly and coordination of the development of the required software, 
including documentation, verification, and establishment of the necessary data base 


ORGANIZATION AND MANAGEMENT 


Because of the change in mission-control operations from KSC to the Mission 
Control Center at MSC and the increased requirements for the later Gemini and early 
Apollo missions, the establishment of an organization responsible solely for the RTACF 
function became necessary. The major problem that occurred in the formation of this 
group was that, if the complement of personnel assigned to this element was to have 
the capability of fulfilling all the requirements, the group would have to have included 
most of the Mission Planning and Analysis Division (MPAD) engineers assigned the 
task of Apollo mission planning. (The MPAD personnel had overall responsibility 
for the RTACF function. ) Thus, a decision was made to establish only a small group 
composed of engineers who were familiar with most aspects of mission planning and 
mission operations. This group was assigned the responsibility of organizing and 
managing the overall RTACF function. The group also was responsible for assessing 
the requirements for feasibility, assigning the requirements to appropriate individuals 
within MPAD, establishing hardware and software control procedures, establishing 
operating procedures, coordinating the RTACF activities, and acting as the single 
point of contact with outside organizations. 

To keep all personnel involved informed of the RTACF procedures, requirements, 
and schedules, a formal documentation procedure was established and followed by the 
RTACF organizational group. The documents, which were published for each mission, 
established the RTACF management structure; maintained the current description of 
the RTACF requirements, software, and data base; and maintained a description of the 
current procedures. The management structure and requirement processing procedures 
were contained in the operational support plan. A flight annex to this document was 
published on a mission -by -mission basis to describe the RTACF software capabilities. 

A work-plan schedule and the data base also were published on a mission-by -mission 
basis. 
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The activities of the organization were different for the prelaunch mission- 
planning phase and for the simulation and real-time mission -control activities. During 
the prelaunch mission-planning phase, the assigned personnel were engaged primarily 
in deciding what requirements could be accommodated, assembling the proper computer 
programs, verifying exercises, developing operating procedures, developing and coor- 
dinating work schedules, assigning other personnel for specific support, and developing 
the required data base. 

During the simulation and real-time mission -control activities, the personnel of 
this organizational group were supervisors and partial staff for the Flight I^namics 
Staff Support Room (FDSSR) and the Auxiliary Computer Room (ACR). These personnel 
provided a central point of contact in the FDSSR and in the ACR, thus eliminating the 
conflicts that had arisen during previous methods of operation and establishing a single 
data-flow channel. The lines of communication and data flow for this period of activi- 
ties are shown in figure 1. Handbooks were published for each mission, detailing the 
coordination procedures between the FDSSR and the ACR and the program setup 
procedures for the ACR. 



- Direction and data flow 

— — Consultation 


Figure 1. - The RTACF communications and data flow during the Apollo Program. 














As can be noted from figure 1, to perform effectively, the ACR required person- 
nel of varied specialties. The RTACF was manned on a three -shift basis for the Apollo 
Program and was a significant user of available resources. The numbers of man-hours 
expended for mission and mission-simulation support for some of the Apollo missions, 
including both computer support and trajectory specialist support, are shown in table I. 
During the early Apollo missions, the ACR was staffed essentially by the engineers 
responsible for the premission planning; but, as the mission complexity grew, the 
requirements for premission planning grew. Eventually, the premission planning engi- 
neers could not devote adequate time to the RTACF fimction. As a result, the perma- 
nent staff of the organization had to be enlarged, and the planning engineers were used 
only as consultants. 


TABLE I. - MANPOWER EXPENDITXJRE FOR THE RTACF 


Mission 

Mission type 

Manpower, 
, a 

man -hr 

Approximate 

mission 

duration 

Apollo 5 

Unmanned LM°, earth orbit 

6375 

6 hr 

Apollo 6 

Unmanned CSM^, earth orbit, 
high speed entry 

3426 

12 hr 

Apollo 7 

First manned CSM, earth 
orbit 

NA^ 

11 days 

Apollo 8 

Manned CSM, lunar orbit 

3783 

6 days 

Apollo 9 

Manned CSM/LM, earth orbit 

9246 

10 days 

Apollo 10 

Manned CSM/LM, lunar orbit 

4880 

8 days 

Apollo 11 

First manned lunar landing 

7644 

8 days 

Apollo 12 

Second manned lunar landing 

894 

10 days 


Si 

hicludes both mission and mission-simulation support. 
^Lunar module. 

Q 

Command and service module. 

*^ot available. 
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FACILITY 


The interfaces of the RTACF within the mission -control operations and the MSC 
Central Data Facility are shown in figure 2. The RTACF provided a centralized work 
area (the ACR) with voice links to the Mission Control Center FDSSR and to the RTCC. 
Data lines connected the ACR to the computers located in the Central Data Facility. 

Data generated in the ACR could be transmitted by means of video to any area within 
the MCC . The RTACF used the general-purpose computing hardware that was used by 
the trajectory analysts for premission design work. Special priority arrangements 
were coordinated with the Computation and Analysis Division for immediate access to 
the computers during simulation and real-time support periods. A diagram of the com- 
puting hardware used by the RTACF" is shown in figure 3. 



KSC wind 
profiles 


Telephone line 


Figure 3. - The RTACF computing - 
hardware configuration. 


operate the RTACF. The KSC interface 
was redundant because of the mandatory 
requirements of the data received from 
KSC. The two interfaces with the MSC 
Central Data Facility were required to 
accomplish all the tasks in the proper 

time, as well as to provide redundancy. The RTACF had the capability to support the 
activities in both Mission Operations Control Rooms in the MCC. Each Mission Opera- 
tions Control Room is located on a separate floor in the MCC. Voice and video commu- 
nications were established between the ACR and the FDSSR on each floor and between 
the staff support rooms on each floor. 


The number of computer hours used in support of some of the Apollo missions 
is given in table n. As would be expected, the hours required depended greatly on the 
complexity of the mission but also depended heavily on the overall confidence in the 
real-time system. 
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Mission 

Mission type 

Computer 
usage, hr^ 

Approximate 

mission 

duration 

Apollo 5 

Unmanned LM , earth orbit 

149 

6 hr 

Apollo 6 

Unmanned CSM , earth orbit , 
high-speed entry 

154 

12 hr 

Apollo 7 

First manned CSM, earth orbit 

565 

11 days 

Apollo 8 

Manned CSM, lunar orbit 

630 

6 days 

Apollo 9 

Manned CSM/LM, earth orbit 

645 

10 days 

Apollo 10 

Manned CSM/LM, lunar orbit 

613 

8 days 

Apollo 11 

First manned lunar landing 

256 

8 days 

Apollo 12 

Second manned lunar landing 

52 

10 days 


21 

Includes both mission and mission-simulation support. 
Lunar module. 

(2 

Command and service module. 

SOFTWARE A/IANAGEMENT AND CONTROL 


In general, the computer programs used in the RTACF were obtained from the 
existing mission design/analysis program and were incorporated into the RTACF com- 
puter system without change to the basic logic and equations. During the mission, the 
programs were run in a batch-processing mode, which is similar to the premission 
planning mode. To establish the proper level of confidence in the RTACF, the software 
had to be controlled and verified in a manner similar to that in the real-time system. 


Software-Configuration Control 

The responsibility for providing mission-critical computations and the significant 
increase in offline computing requirements necessitated the implementation of a strong 
configuration control over the offline computing software modules, including the module 
interfaces, inputs, and outputs. The program logic and equations were supplied by the 
mission-design engineer, and neither was altered by RTACF personnel. 
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In addition to providing a configuration control over the RTACF software, the 
program -interface-control concept also reduced significantly both the manpower and 
the computer time that were required to update the RTACF system. These reductions’ 
were accomplished by providing a common format and program location for the 
mission -dependent constants. Also, job turnaround was improved and human errors 
were decreased significantly by having the computer transfer automatically from mod- 
ule to module. Instead of having the inputs manually keypunched for each individual 
module . 

The trajectory ephemeris tape and the 200-Word Record were the automatic pro- 
gram interfaces that were used during the Apollo Program. The ephemeris tape con- 
tained position and velocity-vector data and spacecraft-attitude information for one or 
two spacecraft. This tape was written by the basic RTACF integrator (the Apollo 
Reference Mission Program), which had both free-flight and powered-flight capabil- 
ities. Other programs, such as optics computations and radiation-dose computations, 
that contained no integrator also used the ephemeris tape for input. The 200-Word 
Record was a group of selected quantities (trajectory information, guidance quantities, 
maneuver parameters, and so forth) that were used to initialize the other programs. 
This interface record was the basis of the RTACF modular mission-support program. 
From this record, the RTACF personnel were able to construct computer programs 
from combinations of the programs that were furnished by the mission -planning engi- 
neers. The data deck setup was simplified because the mission -support personnel had 
to initialize only one program, which in turn provided most or all of the initialization 
parameters to the other modules. Also, the modular concept reduced redundancy in 
the RTACF programs because the capability of one program did not have to be imple- 
mented into a second program. Vertfication of the RTACF programs was reduced 
greatly by the modular concept because each module was a verified mission -planning 
tool. 


Prog ram- Input Control 

Primarily, RTACF control of the program inputs was accomplished by the use 
of a common data base. This data base, located on a FASTRAND drum (as were most 
of the programs themselves), contained most input data that were required by the tra- 
jectory program (that is, launch data, aerodynamic data, center-of-gravity data, 
thrusts, radar-station locations, and so forth). In addition to providing a tool for 
ensuring correct program inputs, the common-data-base concept greatly simplified 
the revision of program input values. Before the data base became operational, 
RTACF personnel updated and checked each program individually. The data base 
provided the capability to input the proper values into a single drum file that was avail- 
able to all programs, thus eliminating the individual program checks. 


Program Verification 


The RTACF programs that provided backup computations for the RTCC were 

of both formal and informal runs with the RTCC. Formal verifica- 
computations from both the RTCC and the RTACF. The informal 
by RTACF personnel during mission simulations by 
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computing selected cases that were run by the RTCC. These computations were coor- 
dinated with Flight Control Division personnel. Compatibility with the mission-planning 
programs provided verification of the computations that were not in the RTCC. Also, 
checks were made with programs that were used to support earlier missions. 


Major Contributions to the Apollo Program 

During the Apollo mission-simulation activities, the RTACF provided support 
for the simulations with the Mission Evaluation Simulator at Downey, California, and 
with the Full Mission Engineering Simulator at Bethpage, New York, before the RTCC 
program was ready to support simulations. This type of support provided both flight- 
crew and flight-controller practice and testing of operational procedures before normal 
simulation times. Such support was especially valuable in the early development phases 
of the Apollo Program. 

The RTACF also was used to support the Emergency Mission Control Center at 
the NASA Goddard Space Flight Center. The RTACF programs, which were applied to a 
system-compatible computer at Washington , D. C. , were to be used to guarantee a 
safe return of the spacecraft and crewmen in the event contact with the Houston MCC 
was lost for any reason. The programs were tested before each mission, and system 
incompatibilities were resolved. This mission-by-mission test was required as a 
result of modifications made to the systems between missions. 

Confidence in the RTCC program in preparation for and during the first lunar- 
landing mission was probably the major contribution made by the RTACF to the Apollo 
Program. In addition, numerous specific computations that could be performed only 
in the RTACF contributed significantly to the success of the Apollo missions. The 
following computations were significant. 

1. Earth-resources-photography-experiment support (Apollo 9) 

2. Telescope -pointing data (all lunar missions) 

3. Mass properties and entry aerodynamics for RTCC initialization (all missions) 

4. Launch-pad-abort impact points (mandatory for all missions) 

5. Onboard-navigation support (Apollo 8) 

6. Passive -thermal-control attitudes (all lunar missions) 

7. Pointing data for the Goldstone, California, 210-foot antenna (all lunar 
missions) 


8. Lunar -orbit-insertion crew-chart data (all lunar missions) 

9. Optimized translunar midcourse-correction targeting (Apollo 8 and 10) 
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10 . 


11 . 


12 . 


13. 

computer 


14. 


Transearth midcourse correction (Apollo 8) 

Entry-tracking-ship positioning (all lunar missions) 

Solar -flare -data reduction (all lunar missions) 

Powered-descent-abort polynomial coefficients for the lunar module onboard 
(ApoUo 11) 

Verification of all maneuvers performed (all missions) 


CONCLUDING REMARKS 


The Real-Time Auxiliary Computing Facility provided a level of confidence for 
the Apollo Program that could not have been practically achieved by any other available 
means. For the following reasons, consideration of the need for this t3rpe of function 
should be given to any future large and complex undertaking similar to the Apollo 
Program. 

1. To be reliable, computer programs used in real time may have many con- 
straints that will not permit long-range planning or flexibility. 

2. Large programs run in real time may be too cumbersome or time consuming 
to be feasible or desirable. 

3. Flexibility must be available to accommodate requirements that are recog- 
nized too late in the real-time -program -development activities. 

4. This function provides a means of evaluating computational programs and 
displays before implementation in the real-time systems. 

5. This function is an organized method of using available programs and analyt- 
ical personnel to provide essentially unlimited real-time capability for problem 
resolution. 

A specific organizational group should be given the responsibility for this function 
if sufficient resources are available. If the resources are not available, at least the 
overall management and the hardware and software coordination and control should be 
the responsibility of the group. 

The necessary hardware and interfaces must be made available, depending on the 
complexity of the operation and the mandatory nature of the function. 

The software should be assembled and built from existing analysis programs, and 
strict control should be exercised on input validity, program interfaces, program 
verification, and output formats. The same computer hardware that is used for the 
premission analysis should be used for the real-time function. 
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The assigned personnel should be thoroughly familiar with the real -time - 
operations procedures, operating hardware, operations personnel, program objec- 
tives, and program -planning activities. The personnel should be assigned to the task 
on a full-time basis. 

Consideration should be given early in the development of the real-time system 
to the possibility or desirability of operatii^ with this type of function. Trade-offs in 
resources for the different modes of operation should be studied. A well-understood, 
straightforward operation is most applicable to pure real-time programing; whereas, 
an activity that is extremely complex and not well understood and that is required to 
accommodate a great deal of change and flexibility is more applicable to the RTACF 
type of operation. 

Some formal documentation should be established to keep all personnel generally 
informed, to keep procedures current, to establish work plans, to keep the management 
structure and data flow current, and to document the available software, including 
input and output formats. 


Manned Spacecraft Center 

National Aeronautics and Space Administration 
Houston, Texas, February 22, 1972 
924-22-20-00-72 
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